Capacity forecasting based on capacity policies and transactions

ABSTRACT

According to one aspect of the present disclosure, a system and technique for capacity forecasting includes a host having a processor unit and a memory. Resource data associated with an environment is stored in the memory having inventory information of storage resources of the environment. A ledger module executable by a processor unit accesses policy data associated with data archival and creates an archival transaction. The ledger module targets data for the archival transaction, links at least one storage resource to the archival transaction, and forecasts a change in capacity of the linked storage resource for the archival transaction based on the policy data.

BACKGROUND

The growth rate of information may far exceed information technology(IT) budgets for storing and/or managing such data. For example,accumulating and storing data can become expensive as additional storageresources may be needed to accommodate the continued accumulation andstorage of such data. Many IT processes may call for evaluating methodsfor reducing such costs, such as reducing the amount of data stored,archiving data in lower cost storage devices, disposing of data, ordecommissioning unused resources.

BRIEF SUMMARY

According to one aspect of the present disclosure a system and techniquefor capacity forecasting is disclosed. The system includes a host havinga processor unit and a memory. Resource data associated with anenvironment is stored in the memory having inventory information ofstorage resources of the environment. A ledger module executable by aprocessor unit accesses policy data associated with data archival andcreates an archival transaction. The ledger module targets data for thearchival transaction, links at least one storage resource to thearchival transaction, and forecasts a change in capacity of the linkedstorage resource for the archival transaction based on the policy data.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

For a more complete understanding of the present application, theobjects and advantages thereof, reference is now made to the followingdescriptions taken in conjunction with the accompanying drawings, inwhich:

FIG. 1 is an embodiment of a network of data processing systems in whichthe illustrative embodiments of the present disclosure may beimplemented;

FIG. 2 is an embodiment of a data processing system in which theillustrative embodiments of the present disclosure may be implemented;

FIG. 3 is a diagram illustrating an embodiment of a computingenvironment in which illustrative embodiments of a capacity forecastingsystem according to the present disclosure may be implemented; and

FIG. 4 is a flow diagram illustrating an embodiment of a method fordynamic reconfiguration of network devices for outage predictionaccording to the present disclosure.

DETAILED DESCRIPTION

Embodiments of the present disclosure provide a method, system andcomputer program product for capacity forecasting based on enterprisepolicies and capacity-related events. For example, in some embodiments,the method and technique includes: storing, in a memory, resource dataassociated with an environment, the resource data comprising inventoryinformation of applications, processing resources and storage resourcesof the environment; and providing a ledger module executable by aprocessor unit to: create a capacity-associated transaction; identifyand link at least one of an application, processing resource and storageresource to the transaction from the resource data; determine aninitiation time and duration associated with the transaction; andforecast a change in capacity of at least one linked storage resourcefor the transaction and a time of the change in capacity. Thus,embodiments of the present disclosure enable capacity-relatedtransactions to be created, edited, deleted, duplicated, prioritized,and a history of changes recorded and viewed. A ledger module accordingto the present disclosure enables planning scenarios to be evaluated andgoals to be set in terms of cost and capacity savings. Once acapacity-related transaction scenario has been created, users canadd/remove existing ledger transactions and organize them in a series orwave of activities. Transactions may be evaluated for freed/consumedcapacity, and key metrics may be compared for several scenarios(combined freed/consumed capacity, duration, costs, number oftransactions, timing, etc.). Once a planned transaction is confirmedand/or carried out, actual capacity change values for the freed andconsumed capacity may be entered/determined and used for futureforecasting.

As will be appreciated by one skilled in the art, aspects of the presentdisclosure may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present disclosure may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present disclosure may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer usable or computer readablemedium(s) may be utilized. The computer readable medium may be acomputer readable signal medium or a computer readable storage medium. Acomputer readable storage medium may be, for example but not limited to,an electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system, apparatus, or device, or any suitable combinationof the foregoing. More specific examples (a non-exhaustive list) of thecomputer readable storage medium would include the following: anelectrical connection having one or more wires, a portable computerdiskette, a hard disk, a random access memory (RAM), a read-only memory(ROM), an erasable programmable read-only memory (EPROM or Flashmemory), an optical fiber, a portable compact disc read-only memory(CD-ROM), an optical storage device, a magnetic storage device, or anysuitable combination of the foregoing. In the context of this document,a computer readable storage medium may be any tangible medium that cancontain, or store a program for use by or in connection with aninstruction execution system, apparatus or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present disclosure are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablemedium produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide processes for implementing the functions/actsspecified in the flowchart and/or block diagram block or blocks.

With reference now to the Figures and in particular with reference toFIGS. 1-2, exemplary diagrams of data processing environments areprovided in which illustrative embodiments of the present disclosure maybe implemented. It should be appreciated that FIGS. 1-2 are onlyexemplary and are not intended to assert or imply any limitation withregard to the environments in which different embodiments may beimplemented. Many modifications to the depicted environments may bemade.

FIG. 1 is a pictorial representation of a network of data processingsystems in which illustrative embodiments of the present disclosure maybe implemented. Network data processing system 100 is a network ofcomputers in which the illustrative embodiments of the presentdisclosure may be implemented. Network data processing system 100contains network 130, which is the medium used to provide communicationslinks between various devices and computers connected together withinnetwork data processing system 100. Network 130 may include connections,such as wire, wireless communication links, or fiber optic cables.

In some embodiments, server 140 and server 150 connect to network 130along with data store 160. Server 140 and server 150 may be, forexample, IBM® Power Systems™ servers. In addition, clients 110 and 120connect to network 130. Clients 110 and 120 may be, for example,personal computers or network computers. In the depicted example, server140 provides data and/or services such as, but not limited to, datafiles, operating system images, and applications to clients 110 and 120.Network data processing system 100 may include additional servers,clients, and other devices.

In the depicted example, network data processing system 100 is theInternet with network 130 representing a worldwide collection ofnetworks and gateways that use the Transmission ControlProtocol/Internet Protocol (TCP/IP) suite of protocols to communicatewith one another. At the heart of the Internet is a backbone ofhigh-speed data communication lines between major nodes or hostcomputers, consisting of thousands of commercial, governmental,educational and other computer systems that route data and messages. Ofcourse, network data processing system 100 also may be implemented as anumber of different types of networks, such as for example, an intranet,a local area network (LAN), or a wide area network (WAN). FIG. 1 isintended as an example, and not as an architectural limitation for thedifferent illustrative embodiments.

FIG. 2 is an embodiment of a data processing system 200 such as, but notlimited to, client 110 and/or server 140 in which an embodiment of asystem for capacity forecasting for an environment according to thepresent disclosure may be implemented. In this embodiment, dataprocessing system 200 includes a bus or communications fabric 202, whichprovides communications between processor unit 204, memory 206,persistent storage 208, communications unit 210, input/output (I/O) unit212, and display 214.

Processor unit 204 serves to execute instructions for software that maybe loaded into memory 206. Processor unit 204 may be a set of one ormore processors or may be a multi-processor core, depending on theparticular implementation. Further, processor unit 204 may beimplemented using one or more heterogeneous processor systems in which amain processor is present with secondary processors on a single chip. Asanother illustrative example, processor unit 204 may be a symmetricmulti-processor system containing multiple processors of the same type.

In some embodiments, memory 206 may be a random access memory or anyother suitable volatile or non-volatile storage device. Persistentstorage 208 may take various forms depending on the particularimplementation. For example, persistent storage 208 may contain one ormore components or devices. Persistent storage 208 may be a hard drive,a flash memory, a rewritable optical disk, a rewritable magnetic tape,or some combination of the above. The media used by persistent storage208 also may be removable such as, but not limited to, a removable harddrive.

Communications unit 210 provides for communications with other dataprocessing systems or devices. In these examples, communications unit210 is a network interface card. Modems, cable modem and Ethernet cardsare just a few of the currently available types of network interfaceadapters. Communications unit 210 may provide communications through theuse of either or both physical and wireless communications links.

Input/output unit 212 enables input and output of data with otherdevices that may be connected to data processing system 200. In someembodiments, input/output unit 212 may provide a connection for userinput through a keyboard and mouse. Further, input/output unit 212 maysend output to a printer. Display 214 provides a mechanism to displayinformation to a user.

Instructions for the operating system and applications or programs arelocated on persistent storage 208. These instructions may be loaded intomemory 206 for execution by processor unit 204. The processes of thedifferent embodiments may be performed by processor unit 204 usingcomputer implemented instructions, which may be located in a memory,such as memory 206. These instructions are referred to as program code,computer usable program code, or computer readable program code that maybe read and executed by a processor in processor unit 204. The programcode in the different embodiments may be embodied on different physicalor tangible computer readable media, such as memory 206 or persistentstorage 208.

Program code 216 is located in a functional form on computer readablemedia 218 that is selectively removable and may be loaded onto ortransferred to data processing system 200 for execution by processorunit 204. Program code 216 and computer readable media 218 form computerprogram product 220 in these examples. In one example, computer readablemedia 218 may be in a tangible form, such as, for example, an optical ormagnetic disc that is inserted or placed into a drive or other devicethat is part of persistent storage 208 for transfer onto a storagedevice, such as a hard drive that is part of persistent storage 208. Ina tangible form, computer readable media 218 also may take the form of apersistent storage, such as a hard drive, a thumb drive, or a flashmemory that is connected to data processing system 200. The tangibleform of computer readable media 218 is also referred to as computerrecordable storage media. In some instances, computer readable media 218may not be removable.

Alternatively, program code 216 may be transferred to data processingsystem 200 from computer readable media 218 through a communicationslink to communications unit 210 and/or through a connection toinput/output unit 212. The communications link and/or the connection maybe physical or wireless in the illustrative examples.

The different components illustrated for data processing system 200 arenot meant to provide architectural limitations to the manner in whichdifferent embodiments may be implemented. The different illustrativeembodiments may be implemented in a data processing system includingcomponents in addition to or in place of those illustrated for dataprocessing system 200. Other components shown in FIG. 2 can be variedfrom the illustrative examples shown. For example, a storage device indata processing system 200 is any hardware apparatus that may storedata. Memory 206, persistent storage 208, and computer readable media218 are examples of storage devices in a tangible form.

FIG. 3 is a diagram illustrating a computing environment in which anembodiment of a system 300 for capacity forecasting according to thepresent disclosure may be implemented. In the illustrated embodiment,system 300 includes a host 302 such as, but not limited to, client 110and/or server 140, having a processor unit 310 and a memory 312. In FIG.3, memory 312 includes a ledger module 320 for forecasting storagecapacity and/or changes in storage capacity for one or more storageresources of the environment based on capacity-associated transactions.Ledger module 320 may be implemented in any suitable manner using knowntechniques that may be hardware-based, software-based, or somecombination of both. For example, manager 320 may comprise software,logic and/or executable code for performing various functions asdescribed herein (e.g., residing as software and/or an algorithm runningon a processor unit, hardware logic residing in a processor or othertype of logic chip, centralized in a single integrated circuit ordistributed among different chips in a data processing system). In someembodiments, ledger module 320 is configured to forecast the capacitythat is going to be freed, or forecast changes in capacity of differentstorage resources, due to capacity-freeing actions in anenterprise/environment. Various capacity freeing actions or activities,hereinafter referred to as transactions, are received and tracked inledger module 320. These transactions tie a specific action or activityto a specific environment type (e.g., production, quality assurance,test, etc.), location (e.g., data center), array type (e.g., tier ofstorage resource), array serial number, server name (host), instancename, database name, and quantity of capacity in a given month, forexample. Each transaction has planned and actual impact entries inledger module 320, and each transaction has a planned start/initiationdate or time and duration.

In the embodiment illustrated in FIG. 3, memory 312 also includes policydata 322, transaction data 324, capacity data 326 and resourceenvironment data 328. Policy data 322 may comprise informationassociated with various enterprise/environment rules or policies forperforming certain activities/transactions, time periods for retainingcertain types of data, archive procedures, etc. For example, in theillustrated embodiment, policy data 322 includes application instances330, archival 332 and storage duration 324 policies. However, it shouldbe understood that policy data 322 may include other types ofpolicy-based rules and/or policy-based transactions for a particularenterprise. Application instances 330 policies may indicate the numberof instances of particular programs or applications of an enterprise,including the location of such instances (e.g., host/server locations),the operating environment of such instances (e.g., production and/ortest), etc. Archival 332 policies may indicate certain rules and/orpolicies associated with data backup operations and the locations forarchived data. Storage duration 334 policies may indicate certain rulesand/or policies for data retention, such as according to regulatoryrequirements, internal operating requirements, business requirements(e.g., accounting and/or legal requirements), etc.

Resource environment data 328 includes inventory information associatedwith various computing resources and/or the computing environmenttopology of an enterprise. For example, data 328 may include informationassociated with different operating/business environment types (e.g.,production, quality assurance, test, etc.), the locations and/orquantity of certain computing resources (e.g., data center locations,application instances), array types (e.g., tiers of storage resources,such as tier 1 storage for current data, tier 2 storage for backup orarchived data, etc.), array serial number, server name (host), instancename (e.g., application instances), database name, etc. Data 328 may bediscovered automatically (e.g., via various environment discovery tools)and/or may be loaded manually via a user/administrator.

Transaction data 324 comprises the transactions affecting storagecapacity that may be loaded/stored/tracked by ledger module 320.Transactions 324 tie a specific action or activity to certain resourcesof the environment, such as application instances, processing resources(e.g., hosts/servers), and storage resources. Ledger module 320 tiesand/or otherwise links applications to processing resources to storageresources for capacity-freeing activities planned or performed. Eachtransaction 324 maintained by ledger module 320 reflects an act of workor activity performed at a point in time. Some transactions 324increment the storage resource capacity pool because the act of work oractivity results in capacity freed, and some transactions 324 decrementthe storage resource capacity pool for capacity consumption as a resultof another transaction 324. For example when data is archived, capacitymay be freed up in a higher, more expensive storage resource array/tierbut used up (usually smaller amount due to compression) in a lower, lessexpensive storage resource array/tier used for archiving. Ledger module320 ties a specific amount of storage resource capacity to thetransaction 324 (e.g., increased capacity for one storage resourceand/or decreased capacity for another storage resource).

There may also be different types of transactions 324 such as, but notlimited to: 1) Archiving of data, compression and movement of data fromone tier to another (e.g., primary archiving action, post-archivedatabase maintenance for non-production environments, by-productbenefits, due to archiving, that remove history copies or duplicate datastores which functioned as archives, and backup reduction as a functionof an archive); 2) Policy changes that reduce or eliminate data volumes(e.g., policy change limiting the non-production instances ofapplications on primary storage tiers, policy change on duration forwhich the back-up data is stored, and policy change on retention periodof production and archive data); 3) Tiering of data that shifts a volumeto lower-cost storage; 4) Deletion of data that eliminates the need forstorage (e.g., deletion of legacy data unrelated to archiving, retentionand typically from orphan data, deletion of sequestered data released ofa legal hold, deletion of legacy data unrelated to archiving and byapplying the retention schedule); 5) Decommissioning of anasset/resource that eliminates stored data or asset cost (e.g.,decommissioning of a server, decommissioning of an application, etc.);and 6) Recurring capacity reduction as a result of a policy change(e.g., monthly amount of capacity consumption avoided on a go-forwardbasis from a cumulative, recurring action that is eliminated or whosevolume is reduced). It should be understood that other types oftransactions 324 may also be used/identified.

Some transactions 324 may be referred to as “triggered” transactiontypes that will be automatically be created by ledger module 320 alongwith a new transaction 324 of a given type when created. For example,triggered transactions 324 may be defined by tying a transaction type toan environment pool or a specific environment. Additionally, triggeredtransactions 324 can be defined in a way that can control when atriggered transaction 324 should start relative to a parent transaction(e.g., same time, upon completion of the main transaction or customoffset). Triggered transactions 324 can also have their own triggeredtransactions, thereby creating a cascade of triggered transactions. Forexample, for a given transaction type (e.g., archival—primary), therecould be defined one of more triggered transaction types (e.g.,archival—maintenance (for all “non-production” environments that shouldstart upon completion of the main transaction) and policychange—limiting the number of non-production environments).

Capacity data 326 may comprise information associated with changes instorage resource capacity based on transactions 324. For example, in theillustrated embodiment, capacity data 326 comprises forecast capacitydata 340 and actual capacity data 342. Forecast capacity data 340 maycomprise the forecast change in capacity for a storage resourceassociated with a transaction 324 (e.g., an increase in capacity due toan archiving process). Actual capacity data 342 may comprise informationassociated with current, actual storage resource capacity and/or anactual change in storage resource capacity resulting from the actualcompletion of a transaction 342. For example, forecast capacity data 340may indicate a future, predicted capacity (or change in capacity) for aparticular storage resource if a particular transaction 324 isperformed. In response to completion of a particular transaction 324,the actual capacity (or change in capacity) for the correspondingstorage resource may be determined (automatically and/or manually). Insome embodiments, ledger module 320 may utilize capacity data 340 and342 to perform future capacity forecasting (e.g., taking into accountand learning from differences between the forecast capacity change andthe actual capacity change for a particular transaction 324).

In the illustrated embodiment, ledger module 320 comprises a ledgerinterface 350. Ledger interface 350 may comprise a graphical userinterface (GUI) or other type of interface enabling a user (e.g., a freecapacity planner, free capacity architects, etc.) to interface withledger module 320 (e.g., entering transactions 324,identifying/verifying linked resources associated with certaintransactions 324, prioritizing activities/transactions 324 towardsspecific applications and data storage resources based on the storageutilization metrics, legal risks, skills required and costs, etc.). Forexample, a new ledger transaction 324 may be created by tying specificinstance of an application/data storage resource in a specificenvironment to a transaction 324 type. Application and data storageresource inventory information (e.g., as set forth in environment data328) and made available through user functionality may enable searchingbased on variety of applications and data storage resource attributessuch as name, code, criticality, confidentiality level, vendor, status,associated organization, data source category, online data range,location, jurisdiction etc. In some embodiments, different computingenvironments may be globally defined in environment data 328 and splitinto “production” and “non-production” pools (or other applicable pooldesignations depending on the application). For example, production anddisaster recovery environments may belong to the “production” pool,while test and quality assurance environments may be part of the“non-production” pool. The amount of processing effort and duration ofthe transaction 324 can often depend on the complexity of theapplication. A transaction 324 type may define a “tiered” duration modelthat enables specifying a default duration of the transaction 324 as afunction of the application complexity.

Interface 350 may also enable certain transaction 324 to be included ornot included (e.g., filtered) for certain planned activities. Forexample, a user can determine which transactions 324 to include andexclude in a particular capacity forecast. Interface 350 may beconfigured to enable changes to individual transactions 324 to berecorded in an audit trail. Further, multiple forecasts, work-startreports and quarterly actual reports can be produced from ledger module320 via interface 350 including scenario forecasts with varyingsensitivities. Interface 350 may enable work planning by transaction 324type and time period to be performed/evaluated (e.g., work-start reportscan be prepared and used to orchestrate activities, transactions 324 maybe sorted by type and start date, identify activities to be initiated byapplication, server, data center, array, etc., and target completiondata, etc.).

Thus, in operation, in some embodiments, each transaction 324 may beassigned/given a unique entry and/or identification (ID). Thetransaction 324 may be policy-based (e.g., derived from policy data322), user-created, or a combination thereof. A particular transaction324 may also comprise a family of transactions (e.g., a transactionassociated with one storage resource may impact capacity changes inanother storage resource). Ledger module 320 may tie/link a specificinstance of an application/storage resource in a specific environment toa particular transaction 324. For example, in FIG. 3, an applicationinventory 360 (e.g., derived from environment data 328) may includevarious applications used in the environment/enterprise, such asapplication 362. Different data source 363 environments (e.g., aproduction (PROD) environment 364, a test (TEST) environment 366 and adisaster recovery (DR) environment 368) may each use one or moreinstances of application 362 (e.g., applications 362 ₁, 362 ₂ and 362 ₃,respectively). Instances of the application 362 may also be linked tovarious processing resources 370, such as database servers 372, 374 and376 and file servers 378, 380 and 382, respectively. Correspondingly,processing resources 370 may be linked/associated with a storageresource inventory 390 including storage assets such as storageresources 392, 394, 396 and 398. The storage assets of the storageresource inventory 390 may be further distinguishable based on atier/array level of such resource (e.g., storage resources 392 and 398may comprise a more expensive tier I resource, storage resource 396 maycomprise a less expensive tier II resource, and storage resource 396 maycomprise a least expensive tier III resource).

Ledger module 320 automatically estimates the transaction 324 durationbased on the complexity of the transaction (e.g., based on thecomplexity of the application identified in environment data 328 and atiered transaction duration definition as specified in the transactiontype; based on the quantity of data to be processed (e.g., the amount ofdata, data compression requirements, etc.), the quantity of resources tobe processed (e.g., multiple data storage resources), etc.) and forecastchanges in capacity for various storage resources 390. Ledger module 320may also automatically generate triggered transactions 324 per atransaction type definition for all the applicable instance of theapplication. For example, referring to FIG. 3, application 362 can bedefined in environment data 328 as having three associated data sourceinstances (e.g., applications 362 ₁, 362 ₂ and 362 ₃) in variousenvironments (e.g., production 364, test 366 and disaster recovery 368).A transaction type (e.g., archival—primary) may only be applicable tostorage resources in the production environment where triggeredtransactions (e.g., archival—maintenance) may be applicable tonon-production environments. When a new transaction 324 is created(e.g., archival—primary) for the production environment, ledger module320 would automatically generate two archival—maintenance triggeredtransactions 324 for other environments (e.g., test and disasterrecovery).

Ledger module 320 forecasts changes in capacity for one or more storageresources 390 based on the transaction 324 (e.g., base transaction and,when applicable, triggered transactions) by time (e.g., when thecapacity change will occur), array type (tier) and datacenter/environment (e.g., production, test, etc.). The forecast capacitydata 340 may thereby be used to evaluate future purchase and capacitygrowth planning and may drive storage resource reclamation workplanning. Ledger module 320 may be used to identify cost savings andavoidance actions from which benefits are realized (e.g., freed storagecapacity can be consolidated, storage devices or arrays may be removedfrom service and their cost eliminated, free capacity can bere-allocated to avoid purchase of new capacity, etc.). Ledger module 320may also indicate/identify certain storage resources, or data associatedtherewith, that may be consolidated and/or decommissioned (e.g.,identifying data on multiple same-tier resources that may beconsolidated to facilitate decommissioning of a resource).

FIG. 4 is a flow diagram illustrating an embodiment of a method forcapacity forecasting according to the present disclosure. The methodbegins at block 402, where a selection and/or indication of a particulardata capacity-related source is received (e.g., a particularapplication, computing environment, processing resource, storageresource, etc.). In some embodiments, interface 350 may be used by anadministrator/user to identify a capacity-related data source and/orresource for which a transaction 324 may be created. It should beunderstood that the process and/or method of creating a transaction 324may vary (e.g., identifying a particular environment and then beingpresented with a list of applications/data sources for which atransaction may be created; selecting an application and then beingpresented with different environments in which instances of theapplication are deployed; etc.). At block 404, ledger module 320 maydetermine/identify different transaction 324 types applicable to theselected data source (e.g., archival processes, data deletion, etc.) andledger module 320 may thereafter present a list of different transaction324 types for selection by the user to apply or use for the currenttransaction 324.

At block 406, ledger module 320 receives a selection of a particulartype of transaction 324 to apply for the selected resource. At block408, ledger module 320 receives a planned initiation time of thetransaction 324. At block 410, ledger module 320 creates the primary orparent transaction 324 and links and/or ties one or more ofapplications, processing resources and/or storage resources to thetransaction 324. At decisional block 412, a determination is madewhether there are triggered transactions to be created based on thecreated transaction. If not, the method proceeds to block 416. If thereare triggered transactions to be created, the method proceeds to block414, where one or more sibling and/or triggered transactions are createdbased on the primary or parent transaction. In some embodiments, ledgermodule 320 may cycle through the various computing environmentsaccording to environment data 328 and locate additional data sources(e.g., application instances, processing resources and/or storageresources) related to the primary transaction for creating triggeredtransactions. Ledger module 320 may also determine a time and/or timeoffset for the triggered transactions relative to the primarytransaction. For example, ledger module 320 may derive and/or otherwisedetermine whether the triggered transactions may run concurrently withor offset from (e.g., after completion) of the primary transaction. Themethod then proceeds to block 416, where ledger module 320 may determinea duration of the transaction (e.g., the primary transaction and/or anytriggered transaction). At block 418, ledger module 320 forecasts achange in storage resource capacity for one or more storage resourcesbased on the transaction (e.g., the primary transaction and/or anytriggered transactions). Ledger module 320 may update capacity data 326for the forecast information and/or otherwise make such capacity data326 available for review, prioritization, evaluation, etc., by a user ofledger module 320.

Thus, embodiments of the present disclosure enable an easily viewableand accessible overview of capacity planning and forecasting scenarios.Transactions may be created, edited, deleted, duplicated, prioritized,and a history of changes recorded and viewed. Ledger module 320 enablesplanning scenarios to be evaluated and goals to be set in terms of costand capacity savings. Once a scenario has been created, users canadd/remove existing ledger transactions and organize them in a series orwave of activities. Transactions may be evaluated for freed/consumedcapacity, and key metrics may be compared for several scenarios(combined freed/consumed capacity, duration, costs, number oftransactions, timing, etc.). Once a planned transaction is confirmedand/or carried out, actual capacity change values for the freed andconsumed capacity may be entered/determined and used for futureforecasting.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the disclosure.As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present disclosure has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the disclosure in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the disclosure. Theembodiment was chosen and described in order to best explain theprinciples of the disclosure and the practical application, and toenable others of ordinary skill in the art to understand the disclosurefor various embodiments with various modifications as are suited to theparticular use contemplated.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

What is claimed is:
 1. A system, comprising: a host having a processorunit and a memory; resource data associated with a computing environmentstored in the memory, the resource data comprising inventory informationof storage resources of the computing environment; policy data stored inthe memory, the policy data associated with data archival; and a ledgermodule executable by a processor unit to: access the policy data; createan archival transaction based on the policy data; target data for thearchival transaction based on the policy data; link at least one storageresource to the archival transaction from the resource data based on thetarget data; and forecast a change in capacity of the at least onelinked storage resource for the archival transaction based on the policydata.
 2. The system of claim 1, wherein the ledger module is configuredto define the archival transaction to include an initiation time basedon the policy data.
 3. The system of claim 1, wherein the ledger moduleis configured to predict a duration of the archival transaction based onthe target data.
 4. The system of claim 1, wherein the ledger module isconfigured to receive an indication of an actual change in capacity forthe at least one linked storage resource in response to a completion ofthe archival transaction.
 5. The system of claim 1, wherein the ledgermodule is configured to forecast the change in capacity due tocompression of the target data.
 6. The system of claim 1, wherein theledger module is configured to predict a cost change associated with theat least one linked storage resource resulting from the archivaltransaction.
 7. The system of claim 1, wherein the ledger module isconfigured to forecast whether the at least one linked storage resourceis available for decommissioning based on the archival transaction.
 8. Acomputer program product for capacity forecasting for a computingenvironment, the computer program product comprising: a non-transitorycomputer readable medium having computer readable program code embodiedtherewith, the computer readable program code comprising computerreadable program code configured to: access policy data stored in amemory, the policy data associated with data archival; create anarchival transaction based on the policy data; target data for thearchival transaction based on the policy data; access resource datastored in the memory, the resource data including inventory informationof storage resources of the computing environment; link at least onestorage resource to the archival transaction from the resource databased on the target data; and forecast a change in capacity of the atleast one linked storage resource for the archival transaction based onthe policy data.
 9. The computer program product of claim 8, wherein thecomputer readable program code is configured to define the archivaltransaction to include an initiation time based on the policy data. 10.The computer program product of claim 8, wherein the computer readableprogram code is configured to predict a duration of the archivaltransaction based on the target data.
 11. The computer program productof claim 8, wherein the computer readable program code is configured toreceive an indication of an actual change in capacity for the at leastone linked storage resource in response to a completion of the archivaltransaction.
 12. The computer program product of claim 8, wherein thecomputer readable program code is configured to forecast the change incapacity due to compression of the target data.
 13. The computer programproduct of claim 8, wherein the computer readable program code isconfigured to predict a cost change associated with the at least onelinked storage resource resulting from the archival transaction.
 14. Thecomputer program product of claim 8, wherein the computer readableprogram code is configured to forecast whether the at least one linkedstorage resource is available for decommissioning based on the archivaltransaction.
 15. A system, comprising: a host having a processor unitand a memory; resource data associated with a computing environmentstored in the memory, the resource data comprising inventory informationof storage resources of the computing environment; policy data stored inthe memory, the policy data associated with data transactions in thecomputing environment; and a ledger module executable by a processorunit to: access the policy data; determine whether a change in thepolicy data has occurred associated with the data transactions;responsive to determining that a change in the policy data has occurred,link at least one storage resource to the policy data change; andforecast a recurring capacity change for the at least one storageresource based on the policy change.
 16. The system of claim 15, whereinthe ledger module is configured to determine whether the policy changeaffects multiple storage resources of the computing environment.
 17. Thesystem of claim 15, wherein the ledger module is configured to predict acost change associated with the at least one linked storage resourceresulting from the policy data change.
 18. The system of claim 15,wherein the ledger module is configured to receive an indication of anactual change in capacity for the linked storage resource in response toa completion of a data transaction resulting from the policy datachange.
 19. The system of claim 15, wherein the ledger module isconfigured to determine whether the policy change results in capacitychanges in different tiers of the storage resources of the computingenvironment.
 20. The system of claim 15, wherein the ledger module isconfigured to identify a prioritization of a first data transactionrelative to a second data transaction based on the policy data change.